-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support to run yul optimizer assembly test #15009
base: yul_transport_debugdata_attributes_to_assembly_items
Are you sure you want to change the base?
Add support to run yul optimizer assembly test #15009
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see this is pretty much an exact copy of YulOptimizerTest.h
at this point, so I assume it's unfinished. What is actually the idea behind this test? Just displaying the assembly next to the optimized Yul or something more?
e953eca
to
917cec1
Compare
8a4d556
to
de39abd
Compare
de39abd
to
9357780
Compare
Just to answer this: the target here is to test the transport of the debugging context through any individual optimizer step and then to assembly (which is from where we'll output them in the end) In any case, doesn't hurt to have, and not too much of a headache to just merge. |
EVMObjectCompiler::compile( | ||
*m_object, | ||
adapter, | ||
EVMDialect::strictAssemblyForEVMObjects(EVMVersion{}), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why aren't we respecting the dialect and EVM version selected by the user here even though we do in the other places in this test case?
Same question for analyzeStrictAssertCorrect()
above.
Also, it would be a good idea to have something EVM version-specific in the sample test case so that we can see if this works correctly.
m_object->analysisInfo = std::make_shared<AsmAnalysisInfo>( | ||
AsmAnalyzer::analyzeStrictAssertCorrect(EVMDialect::strictAssemblyForEVMObjects(solidity::test::CommonOptions::get().evmVersion()), *m_object) | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it really correct to simply overwrite the previous analysis info? Do we do that in real compilation too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
basically this is needed, because after the optimisation step the code might have slightly changed, so we need to update the analysis info. if this is not done, the evm code transform will fail.
8740a1b
to
b95b101
Compare
7f16255
to
b14086e
Compare
f52ac21
to
9ad6a0d
Compare
b14086e
to
d548cb1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems mostly ok now, except for the DebugAttributeCache
thing - need to understand what that is about and why it's a part of this, seemingly unrelated, PR.
#include <vector> | ||
#include <memory> | ||
|
||
#include <libyul/AsmParser.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be above STL imports.
{ | ||
std::shared_ptr<Object> object; | ||
std::shared_ptr<AsmAnalysisInfo> analysisInfo; | ||
Parser::DebugAttributeCache::Ptr debugAttributeCache = std::make_shared<Parser::DebugAttributeCache>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
YulOptimizerTestCommon
has m_debugAttributeCache
. Shouldn't you be using it here instead?
return TestResult::FatalError; | ||
} | ||
|
||
auto const printed = (object->subObjects.empty() ? AsmPrinter{ dialect }(*object->code) : object->toString(&dialect)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
auto const printed = (object->subObjects.empty() ? AsmPrinter{ dialect }(*object->code) : object->toString(&dialect)); | |
std::string const yulCode = (object->subObjects.empty() ? AsmPrinter{dialect}(*object->code) : object->toString(&dialect)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By the way, would be good to add a simple smoke test that triggers the other branch here to make sure it works as expected.
@@ -67,6 +69,7 @@ class ObjectParser: public langutil::ParserBase | |||
void addNamedSubObject(Object& _container, YulString _name, std::shared_ptr<ObjectNode> _subObject); | |||
|
|||
Dialect const& m_dialect; | |||
Parser::DebugAttributeCache::Ptr m_debugAttributeCache; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do these optimizer changes related to DebugAttributeCache
really belong in a PR that's adding a new test type? Shouldn't they be a part of some other PR specific to debug info?
This is needed in the context of
ethdebug
. I will need to write some tests on how optimiser steps are dealing with the debug attributes defined by #14857. The ideas is to implement different PRs per optimiser step on top of #14969, where this PR will enable the visualisation how these debug attributes got potentially merged - depending on the optimiser step.For context, see e.g. #15087.